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Layerl:  A  SIMULA  Context  for  Simulating  the  Operation 
of  Communication  Systems 

INTRODUCTION 

Layerl  is  a  SIMULA  context  in  which  communication  protocols  can  be  specified  and  simulated. 
Its  name  is  derived  from  the  International  Standards  Organization  (ISO)  reference  model  for  open  sys¬ 
tems  interconnection  (OSD  (1].  Layerl  of  the  ISO/OS1  architecture  specifies  the  physical  means  by 
which  information  is  transported  within  a  communication  system.  Layerl  code  implements  the  physical 
layer  of  a  communication  system  by  providing  a  set  of  SIMULA  classes  (i.e.,  object  templates)  that 
model  communication  hardware  and  its  interaction  with  the  communication  medium.  Thus  one  may 
define  and  experiment  with  communication  protocols  by  using  a  model  of  a  communication  system 
rather  than  the  actual  hardware. 

Layerl  code  provides  a  degree  of  realism  adequate  to  model  frequency-hopped,  HF  radio  com¬ 
munication  systems.  There  are  limitations,  however.  For  example,  no  propagation  models  are  provided 
to  compute  communication  ranges,  although  the  user  can  directly  incorporate  the  procedures  that  per¬ 
form  these  computations  into  the  simulation.  Also,  channels  and  hop  codes  can  be  differentiated,  but 
hopping  patterns  cannot  be  defined  explicitly.  A  receiver  can  detect  primary  (same  channel,  same  hop 
code)  and  secondary  (same  channel,  different  hop  code)  collisions  as  well  as  the  number  of  competing 
signals  involved  in  a  collision.  However,  it  cannot  determine  the  actual  number  of  hits  (same  time, 
same  frequency  hop)  associated  with  a  collision.  Here  again,  the  user  can  supply  procedures  to  specify 
hopping  patterns  and  to  compute  the  number  of  hits  if  additional  detail  is  required  in  the  model.  Thus, 
the  aforementioned  limitations  can  be  removed  by  extending  the  layerl  code.  The  implementation  of 
extensions  such  as  these  is  straightforward. 

In  the  next  section,  we  briefly  describe  the  supporting  context  on  which  layerl  is  built.  Then,  in 
the  following  sections  we  describe  the  kinds  of  objects  provided  by  layerl ,  explain  how  they  work,  and 
show  how  to  use  them  to  design  a  simulation.  In  the  conclusions  we  give  an  assessment  of  our 
approach  to  communication  protocol  simulation,  and  in  the  appendix  we  list  the  SIMULA  code  for  a 
sample  problem. 

SUPPORTING  CONTEXT 

SIMULA  [2]  provides  the  foundation  for  the  supporting  context  in  which  layerl  is  developed. 
SIMULA  is  an  extension  of  ALGOL  (31.  It  adds  to  ALGOL  a  special  SIMULA  construct  called  a  class. 
SIMULA  classes  can  be  used  in  two  distinct  ways.  One  way  is  to  use  a  class  as'a  context.  A  context  is 
a  precompiled  block  of  SIMULA  code  containing  procedures  and  object  templates  that  serve  as  a  set  of 
tools  and,  thus,  extend  the  capability  of  SIMULA  to  handle  problems  in  a  specific  area  of  interest. 
Another  way  to  use  a  class  is  as  an  object  template.  An  object  template  is  used  as  a  pattern  to  create 
one  or  more  objects  of  the  same  type.  This  is  accomplished  by  using  the  SIMULA  new  construct,  and 
an  object  thus  created  is  called  a  class  instance.  Object  creation  (i.e.,  class  instantiation)  is  illustrated  by 
the  following  SIMULA  statement: 

xmtr:-  NEW  transmitter; 
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The  attribute  xm/r  is  a  special  type  of  SIMULA  variable  called  a  reference  variable.  Reference  variables 
serve  as  pointers  to  class  instances  and  must  be  typed  properly  somewhere  in  the  SIMULA  context.  In 
this  case  we  need  a  type  designation  as  follows: 

REF  (transmitter)  xmtr; 

which  designates  xmtr  as  a  pointer  to  transmitter  objects.  The  symbol  is  read  as  denotes  and  serves 
as  a  replacement  operator  for  reference  variables.  NEW  causes  the  instantiation  to  occur.  Each  class 
instance  in  a  SIMULA  system  is  an  object  with  its  own  set  of  attributes  and  actions.  Therefore,  to 
implement  layerl  we  define  a  set  of  SIMULA  classes  that  provide  templates  for  the  various  communi¬ 
cation  hardware  components.  The  SIMULA  code  that  a  user  of  the  layerl  context  writes  instantiates 
the  classes  as  needed  to  implement  his  particular  communication  system  model.  This  is  analogous  to 
building  a  communication  system  by  assembling  and  interfacing  hardware  components.  We  clarify  this 
technique  in  the  sections  that  follow. 

Finally,  we  rely  heavily  on  the  single-inheritance  capability  of  SIMULA  classes,  in  building  con¬ 
texts  and  in  developing  object  templates.  Class  inheritance  is  effected  by  prefixing  one  class  with 
another.  For  example,  in  Fig.  1  we  depict  the  layerl  context.  The  foundation  of  the  context  is 
SIMULA  itself.  Two  standard  SIMULA  classes,  simset  and  simulation,  are  added  to  SIMULA  and 
together  they  provide  the  context  available  to  every  SIMULA  user.  Next,  we  provide  a  user-written 
class  called  node  stats.  Class  node  stats  has  the  following  form: 

simulation  CLASS  node  stats(max  num  of  nodes); 

INTEGER  max  num  of  nodes;  ! Maximum  number  of  nodes; 

BEGIN 

(code  which  implements  class  node  stats)  ... 

END; 

In  the  first  line  of  nodestats  code  we  see  that  the  class  declaration  for  node  stats  is  prefixed  by  simula¬ 
tion.  This  has  the  effect  of  passing  on  to  class  node_stats  the  entire  context  of  class  simulation,  which  in 
turn  has  the  entire  context  of  class  simset,  which  in  turn  has  the  entire  context  of  SIMULA.  By  the 
time  we  define  msg  queue  class  layerl,  layerl  has  inherited  the  entire  context  that  has  come  before  and 
in  turn  may  pass  it  on  along  with  its  own  classes  (i.e.,  object  templates)  and  procedures  to  any  class  that 
uses  layerl  as  a  prefix. 


LAYER1 

MSG_QUEUE 

CONN.MATRIX 

NODE_EVSIM 

NODESTATS 

SIMULATION 

SIMSET 

SIMULA 

Fig.  1  —  Supporting  context 
for  layerl 

Classes  that  define  object  templates  use  inheritai.ce  in  much  the  same  way  as  classes  that  define 
contexts.  For  example,  let  us  assume  that  we  would  like  to  extend  our  model  of  a  transmitter  to  incor¬ 
porate  features  specific  to  ultrahigh  frequency  (UHF)  transmitters,  which  are  not  modeled  in  the  very 
generalized  class  transmitter.  We  could  do  this  by  defining  a  new  class,  transmitter  class  ul\f_transmitter, 
which  is  then  called  a  subclass  of  class  transmitter.  When  class  uftf  transmitter  is  instantiated,  it  will  be  a 
concatenated  object  containing  the  attributes  and  actions  of  both  class  transmitter  and  class 
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uhfjransmitter.  Other  varieties  of  transmitter  object  templates  may  also  be  defined  using  class 
transmitter  as  a  prefix.  Note:  the  pointer  —  REF(transmitter)xmtr  —  can  point  to  any  concatenated 
object  that  uses  transmitter  to  begin  its  prefix  chain.  Class  inheritance  provides  a  powerful  and  flexible 
capability  for  designing  object  templates  as  well  as  contexts. 

Figure  1  gives  a  pictorial  representation  of  the  layer]  supporting  context,  and  a  verbal  description 
follows: 

•  Simset ,  a  standard  SIMULA  class  (context),  implements  queues  as  two-way  linked  lists  by 
defining  two  new  classes  (templates),  link  and  head.  Any  object  prefixed  by  link  can  be 
inserted  into,  shuffled  around  in  or  removed  from  any  queue  that  is  an  instance  of  class  head. 

•  Simulation ,  another  standard  SIMULA  class,  supports  discrete  event  simulation.  Simulation 
defines  three  new  classes—  link  class  event  notice ,  link  class  process ,  and  process  class 
main program .  Also,  an  instance  of  class  head  is  created  which  serves  as  an  event-notice 
queue.  Simulation  provides  a  set  of  procedures  for  scheduling  event-notices.  When  an 
event-notice  becomes  current,  the  process  referenced  becomes  active.  The  main  program  is 
also  a  process  with  its  own  event-notice,  therefore  it  becomes  another  member  of  the  set  of 
quasi-parallel  processes  that  constitutes  a  SIMULA  system. 

•  Node  stats  is  a  class  that  provides  abstract  data  types  for  statistics  collection  (4)  and  introduces 
the  concept  of  a  node.  The  introduction  of  class  node  at  this  relatively  low  level  in  the  con¬ 
text  facilitates  the  inclusion  of  node  reference  variables  and  class  prefixing  in  tailoring  the 
statistics  collection  and  other  higher  level  contexts  to  a  node  oriented  model. 

•  Nodeevsim  provides  an  event-process  facility  [5]  that  permits  a  process  (i.e.,  an  event- 
process)  to  have  multiple  event  notices  pending  in  the  event  queue.  This  is  an  important 
extension  to  the  SIMULA  process  as  defined  in  class  simulation,  which  permits  each  process 
to  have  only  one  event  notice  in  the  event  queue  at  any  one  time.  Also,  node  evsim  provides 
event  tracing.  Event-processes  play  a  significant  role  in  the  design  of  layer  I  code. 

•  Conn  matrix  supplies  a  template  and  procedures  for  manipulating  connectivity  matrices.  More 
about  this  topic  is  said  later. 

•  Msg  queue  extends  the  basic  queue  handling  facilities  of  class  simset  to  provide  procedures  put 
and  get  [6]  along  with  an  interface  to  a  message  processor. 

•  Layerl  uses  many  of  the  features  just  described  and  adds  to  them  its  own  set  of  classes  and 
procedures  oriented  toward  the  modeling  of  communication  systems. 

The  entire  context  described  above  with  all  its  features  and  capabilities  is  available  to  the  layerl  user. 

LAYER1  OBJECTS 

In  layerl  we  take  advantage  of  the  object-oriented  approach  afforded  by  the  SIMULA  class  con¬ 
struct.  This  approach  allows  us  to  map  directly  from  real  objects,  such  as  transmitters  and  receivers,  to 
SIMULA  classes  that  represent  these  objects.  By  maintaining  a  one-to-one  mapping  of  real  objects  to 
SIMULA  objects,  we  obtain  a  model  that  is  conceptually  identical  to  the  real  system  we  are  modeling. 
Thus,  it  is  easy  to  understand  and  use  the  model.  The  kinds  of  object  templates  (i.e.,  SIMULA  classes) 
provided  by  layerl  are  the  following: 

•  layerlnode 

A  physical  platform  that  can  house  one  or  more  communication  systems. 
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•  channel 

A  portion  of  the  radio  frequency  spectrum  used  to  send  and  receive  radio  transmissions. 
Layerl  channels  provide  communication  paths  for  chan_msgs  to  follow. 

•  chanmsg 

The  layerl  transmission  unit. 

•  isomsg 

Contents  of  a  chan  msg. 

•  multicoupler 

The  focal  point  at  a  layerl_node  which  receives  all  transmissions,  i.e.,  chanmsgs. 

•  receiver 

Receives  chan  msgs  and  extracts  their  information,  i.e.,  iso_msgs. 

•  transmitter 

Packs  link  layer  information,  iso_msgs,  into  chan_msgs  and  sends  them  via  a  channel. 

•  controller 

Manages  a  suite  of  transmitters  and  receivers  by  running  controllersubprognms. 

•  controllersubprogram 

Provides  an  interface  to  the  transmitter  and  receiver  hardware,  which  becomes  a  context  for 
writing  link  layer  protocols. 


Figure  2  presents  a  communication  system  model  constructed  with  layerl  objects.  These  classes  are  now 
discussed  in  detail. 
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LayerlNode 

A  layerlnode  models  a  platform  that  can  house  one  or  more  communication  systems.  A 
layerlnode  object  is  created  in  the  user’s  program  by  the  following  statement: 

nodes  (index):-H  EW  layer  l_node_subclass(id_num,  num_xmtrs,  numrcvrs, 
num_cntrls,layerl_node_subclass  parameter  list); 

In  this  and  the  statements  that  follow  we  use  two  conventions.  The  items  in  boldfaced  should  be  typed 
exactly  as  shown  and  the  italicized  items  represent  quantities,  identifiers  or  code  supplied  by  the  user. 
Class  node  stats  defines  REF(node)  ARRAY  nodes!  l:max_num_of_nodes)  which  is  an  array  of 
pointers  to  node  objects  and  is  inherited  by  layerl.  Since  layerl  node  is  a  subclass  of  node ,  nodes 
pointers  may  be  used  to  point  to  layerl  node  objects.  The  user  can  create  nodes(l),  nodes(2),  etc.,  up 
to  max  num  of  nodes.  That  is,  index  assumes  values  1,  2,  etc.,  not  to  exceed  max_num_of_nodes. 
The  user  specifies  max  num  of  nodes  when  compiling  a  layerl  block  and  thus  places  an  upper  bound 
on  the  number  of  nodes  that  can  be  simulated  with  a  particular  load  module.  Layerl  node  subclass  is 
the  name  of  a  subclass  of  layerl  node  written  by  the  user;  it  has  the  following  form: 

layerl  node  CLASS  layer Inodesubclass  (parameter  list); 
parameter  definitions 

BEGIN 

attributes 

actions 

END; 

The  additional  parameter  list  and  definitions  as  well  as  the  inclusion  of  additional  attributes  are 
optional.  We  say  additional  because  layer  1 _node subclass  inherits  all  the  attributes  and  actions  from  its 
prefix  class,  which  in  this  example  is  class  layerl  node. 

We  now  define  the  four  parameters  specified  in  the  class  layerl  node  parameter  list.  If  the  user 
specifies  a  parameter  list  for  layer  1  node  subclass,  those  parameters  would  be  appended  to  this  list. 
Id  num  is  an  integer  identification  number  for  the  layeii  node  being  created.  It  may  have  the  same 
value  as  the  one  used  for  index,  but  it  is  not  necessary  for  it  to  be  the  same.  Num  xmtrs,  num  rcvrs  and 
num  cntrls  are  integers  that  specify  the  number  of  transmitters,  receivers,  and  controllers  to  be  created 
at  this  node.  In  each  layer  Inodesubclass  object,  the  user  must  create  the  transmitter,  receiver,  and 
controller  objects  residing  at  that  layer  l  noue  and  must  tell  layerl  how  to  interconnect  them.  These 
actions  are  appended  to  the  actions  of  class  layerl  node ,  which  create  a  multicoupler  object.  The  details 
of  these  actions  are  explained  as  we  discuss  other  classes. 

We  close  our  discussion  of  layerlnodes  with  one  last  point,  layerlnodes  need  not  be  all  alike. 
Of  course,  differing  layerlnodes  will  require  differing  layerlnode  subclasses  (e.g., 
layer  1  node  subdass  l.  layer  1_ node _ subclass_ 2,  etc  ).  The  user  creates  as  many  of  each  kind  of 
layerl  node  objects  as  required.  Creation  of  different  layerl  node  objects  and  assignment  of  pointers 
to  array  nodes  is  accomplished  in  just  the  same  way  as  shown  above. 

Channel 

Layerl  nodes  are  connected  to  each  other  via  communication  channels.  Layerl  provides  a  class 
channel.  Channel  objects  can  be  created  with  the  following  procedure  call: 


createphyschans  (numofchans, dynamic); 

Num_of_chans  is  an  integer  that  specifies  the  number  of  channels  to  be  created.  When  a  channel  is 
created,  a  pointer  is  passed  to  REF(channel)  ARRAY  chans!  1  :max_num_of_chans).  The  upper  array 
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bound,  max_num_of_chans,  is  set  by  the  user  when  compiling  a  layer!  block  and  limits  the  number  of 
channels  that  may  be  created  with  that  particular  load  module.  Dynamic  is  a  Boolean  number  that 
determines  whether  or  not  the  channels  will  be  dynamic.  A  dynamic  channel  may  alter  its  connectivity 
matrix  at  any  time  during  the  course  of  a  simulation.  Otherwise  the  channel  is  static  and  altering  its 
connectivity  matrix  will  produce  erroneous  results.  The  only  advantage  of  using  static  channels  is  to 
save  computation  time.  Figure  3  depicts  a  connectivity  matrix. 


transmitting 
12  3  4 

1 
2 

receiving 

4 


Fig  3  —  Example  of  a  connectivity  matrix 
for  a  four  node  network 
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The  row  position  tells  which  node  is  receiving,  and  the  column  position  tells  which  node  is  transmit¬ 
ting.  A  "1"  indicates  connectivity,  a  "0"  indicates  lack  of  connectivity.  For  example,  the  1  at  position-1,3 
indicates  that  node-1  can  hear  node-3.  Note  that  the  matrix  diagonal  contains  0’s.  This  means  the 
nodes  for  this  example  are  not  self  jamming.  Node  pairs  that  have  full  two-way  connectivity  are  (1,2), 
(1,3),  and  (2,4).  One-way  links  exist  from  3  to  4  and  from  4  to  1.  Each  channel  creates  a  connectivity 
matrix  of  its  own,  but  it  does  not  initialize  it.  The  user  can  call  an  initialization  procedure  with  the 
following  statement: 


chans  (index)  .conn.fill  connectivity  matrlx; 


Execution  of  this  statement  will  cause  the  channel  specified  by  the  integer  index  to  be  initialized  by 
prompting  for  input  data  via  the  user’s  terminal.  It  is  possible  to  use  an  alternative  technique  for 
matrix  initialization.  For  example,  one  might  wish  to  compute  the  connectivity  matrix  via  a  propaga¬ 
tion  model  rather  than  enter  the  contents  of  the  connectivity  matrix  manually.  Since  the  procedure 
fillconnectivitymatrix  is  a  SIMULA  virtual  procedure,  it  can  be  virtually  redefined  in  a  subclass  of 
intmatrix  class  connectivity  to  supply  the  alternate  technique.  The  SIMULA  virtual  declaration  is  illus¬ 
trated  by  the  following  line  of  code: 


VIRTUAL:  PROCEDURE  fill_connectivUy_matrix; 


This  virtual  declaration  is  the  first  declaration  in  the  body  of  class  connectivity ,  which  is  a  subclass  of 
class  intmatrix.  Connectivity  is  therefore  said  to  be  inner  to  class  intmatrix.  Because 
fill  connectivity  matrix  has  been  virtually  declared  in  class  connectivity ,  it  becomes  an  attribute  of  that 
class  and  is  accessible  via  dot  notation  just  as  any  other  attribute  of  class  connectivity  would  be.  How¬ 
ever,  because  of  the  virtual  declaration,  the  attributes  and  actions  of  procedure  fill  connectivity  matrix 
need  not  be  specified  in  class  connectivity.  Rather,  they  may  be  specified  in  a  subclass  of  connectivity. 
SIMULA  will  use  the  innermost  specification  for  a  virtual  procedure.  This  makes  it  possible  to  define  a 
default  specification  for  fill  connectivity  matrix  in  class  connectivity ,  and  then  redefine  it  in  a  class  inner 
to  connectivity.  In  fact,  a  virtually  redefined  procedure  may  itself  be  virtually  redefined  in  a  procedure 
inner  to  it  since  SIMULA  uses  the  innermost  specification. 

The  procedure  for  computing  propagation  delays  is  also  a  SIMULA  virtual  procedure.  The  default 
procedure  defined  as  a  layer!  global  procedure  yields  a  value  of  0.0  for  the  propagation  delay.  The 
default  definition  follows: 
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REAL  PROCEDURE  prop  delay  (nl,n2);  REF(node)nl,n2;  prop_delay:=0.0; 


If  one  wishes  to  use  nonzero  propagation  delays,  this  procedure  may  be  redefined  in  a  subclass  of 
layerl.  The  arguments  passed  to  prop  delay  are  pointers  to  the  transmitting  node  and  the  receiving 
node. 


Class  channel  declares  two  virtual  procedures.  Their  default  definitions  follow: 


PROCEDURE  chanstat (t);  VALUE  t;  TEXT  t;; 
PROCEDURE  changraf(t);  VALUE  t;  TEXT  t;; 


If  redefined,  these  procedures  offer  a  convenient  way  to  collect  statistics  (chan  stat)  or  implement 
graphics  (chan  graf)  without  making  modifications  directly  to  the  layerl  code.  Every  time  a  channel 
processes  an  event,  these  procedures  are  called.  The  code  written  in  these  procedures  can  respond  to 
every  event  to  which  a  channel  object  responds  in  order  to  update  statistics  variables  or  execute  graph¬ 
ics  commands.  In  layerl ,  almost  all  state  changes  occur  as  a  result  of  events  being  generated  and  sent 
to  event-process  objects  [51.  Reference  5  explains  event-processes  in  detail  and  lists  the  event-process 
code.  (Other  event-process  classes  in  layerl  besides  channel  are  transmitter ,  receiver ,  multicoupler ,  and 
controllersubprogram) .  Thus  the  code  the  user  writes  for  these  procedures  is  not  handicapped  by  being 
written  externally  to  layerl.  Separate  procedures  for  statistics  collection  and  graphics  are  called  not  out 
of  necessity  but  rather  as  a  means  of  modularizing  the  code.  Transmitter  and  receiver  objects  call 
equivalent  procedures  for  the  same  purpose. 

ChanMsg 

Class  chanmsg  provides  a  template  for  the  layerl  communication  unit.  Chanmsgs  are  never 
used  directly  Instead,  layerl  transmitter  objects  create  chan_msgs  and  send  them.  When  a  chan  msg  is 
created,  the  following  chan  msg  attributes  are  set: 

•  channel 

An  integer  that  designates  which  channel  the  transmitter  sending  the  chan  msg  is  tuned  to. 

•  fhcode 

An  integer  that  designates  which  frequency-hop  code  the  transmitter  sending  the  chan  msg  is 
set  to. 

•  xmtr 

A  ref(transmitter)  pointer  to  the  transmitter  sending  the  chan  msg. 

•  numofinfobits 

An  integer  that  specifies  the  length  of  the  chan  msg.  The  length  of  a  chan  msg  is  deter¬ 
mined  from  the  length  of  the  iso  msg  contained  in  the  chan  msg.  This  will  be  explained 
shortly. 

•  data 

A  ref(iso  msg)  pointer  that  points  to  the  iso  msg  contained  in  this  chan  msg. 
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•  msgid 

Every  chan_msg  is  assigned  a  unique  integer  message  id  to  facilitate  tracing. 

•  origtime 

Every  chan_msg  is  also  marked  with  the  simulation  clock  time  (real)  when  created. 


IsoMsg 

Since  cha^msgs  exist  only  within  layer],  we  need  another  type  of  message  object  to  pass  infor¬ 
mation  through  the  interface  to  layerl.  This  is  the  purpose  of  class  isomsg.  The  only  attribute  of  class 
isomsg  is  an  integer  called  mlength ;  it  specifies  the  length  of  the  iso  msg.  Iso  msg  must  be  used  as  a 
prefix  for  any  class  of  message  objects  using  the  layerl  interface.  The  SIMULA  code  presented  in  the 
appendix  illustrates  this  technique. 

Multicoupler 

The  multicoupler  receives  all  chan_msgs  sent  to  a  node  and  routes  them  to  each  receiver  that  is 
tuned  to  hear  them.  This  is  determined  by  comparing  the  channel  to  which  each  receiver  at  the 
layerlnode  is  set  with  the  channel  of  the  incoming  chan_msg.  The  multicoupler  also  updates  variable 
'arrays  used  for  collision  detection.  The  values  in  these  arrays  may  be  read  by  using  the  following  pro¬ 
cedures: 

•  numprimcollisions  (chan.code); 

The  attribute  chan  is  the  index  number  of  the  channel,  and  the  code  is  the  index  of  the 
frequency-hopped  code.  Num  prim  collisions  returns  the  number  (integer)  of  competing  sig¬ 
nals  in  the  channel  and  on  the  same  code. 

•  numscndcollisions  (chan); 

The  attribute  chan  is  the  channel  index  number.  Num  scnd  collisions  returns  the  number 
(integer)  of  competing  signals  in  the  channel  including  those  on  different  codes. 

E'  layerl  node  creates  its  own  multicoupler  without  assistance  from  the  user. 

Receiver 

To  create  and  properly  initialize  a  receiver  object  requires  the  following  code: 
rcvr  (num)  NEW  receiver!  receiver  object  title  ,  THIS  layerl  node  ,  num  ); 

Num  is  an  integer  in  the  range  I  <  num  ^  numrcvrs  where  numrcvrs  is  the  number  of  receivers 
specified  in  the  argument  list  for  the  layerl  node.  Receiver  objects  should  be  created  by  the 
layerl  node  to  which  they  belong.  The  statement  given  above  should  be  one  of  the  actions  of  a  sub¬ 
class  of  layerl  node  as  explained  in  section  "Layerl  Node".  The  receiver  object  title  is  a  string 
(SIMULA  text  object)  that  will  be  used  for  identification  if  event  tracing  is  requested.  We  recommend 
a  title  similar  to  the  following: 

mergetext  (“receiver  num  at  node  "  ,  inttext(idnum)) 


We  use  procedure  merge  text  to  concatenate  the  text  items  into  one  object  and  procedure  int  text  to 
convert  from  integer  to  text. 
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Once  a  receiver  is  created,  another  action  is  also  necessary  that  tells  the  receiver  to  which  con¬ 
troller  it  is  connected.  For  that  purpose,  the  receiver  has  a  procedure  that  must  be  called  as  follows: 


rcvr  (num)  .identify  cntrl  (cntrlnum)  ; 


A  receiver  may  be  connected  to  only  one  controller,  although  a  controller  may  have  more  than  one 
receiver.  Cntrl  num  is  an  integer  in  the  range  1  <  cntrl  num  <  numcntrls  (section  “LayerlNode”). 

After  having  created  a  receiver  and  having  assigned  it  to  a  controller,  it  is  still  necessary  to 
activate  it.  Activation  of  an  event-process,  such  as  a  receiver  object,  performs  the  object  initialization 
tasks  and  prepares  it  to  receive  events.  Transmitters,  controllers,  and  controllersubprograms  also  nust 
be  explicitly  activated,  as  it  will  be  discussed  later.  The  following  statement  will  activate  a  receiver 
object: 


ACTIVATE  rcvr  (num)  ; 


The  user  interacts  with  receiver  objects  via  an  interface  provided  by  a  controllersubprogram 
object  (section  “Controller”).  This  gives  the  user  access  to  the  following  procedures  for  controlling 
receiver  objects: 

•  selectrcvr  (id); 

The  argument  id  is  an  integer  that  specifies  the  receiver  (as  given  by  num  above)  one  wishes 
to  access  by  means  of  the  interface.  All  procedure  calls  following  the  call  to  select_rcvr  deal 
specifically  with  the  receiver  named  by  id  until  select  rcvr  is  called  with  a  new  id.  If  there  is 
only  one  receiver,  the  select  rcvr  procedure  need  not  be  called. 

•  read  rcvr  num; 

This  integer  procedure  returns  the  index  (id)  of  the  receiver  that  is  currently  selected  (i.e.,  for 
which  the  interface  is  currently  active). 

•  setrcvrchannel  (c); 

The  argument  c  is  an  integer  that  selects  the  new  channel  to  which  the  receiver  is  tuned.  The 
value  given  to  c  corresponds  to  the  channel  index  as  described  in  section  “Channel”. 

•  rcvrchannelnum; 

This  integer  procedure  reads  the  channel  to  which  the  receiver  is  presently  tuned  and  returns 
the  channel  index  value. 

•  set  rcvr  fhcode  (f); 

The  argument  /is  an  integer  that  selects  the  receiver’s  hop  code.  The  value  of  /is  compared 
with  the  hop  code  value  in  chanmsg  as  set  by  the  transmitter  sending  the  chanmsg.  If  the 
values  are  the  same,  then  the  receiver  can  receive  the  chan  msg.  One  does  not  have  to  use 
hop  codes.  If  this  procedure  and  the  corresponding  procedure  for  the  transmitter 
(set  xmtr  fhcode)  are  not  called,  all  hop  code  values  default  to  1.  Thus,  the  comparison  test 
mentioned  above  will  always  be  true,  in  effect  it  eliminates  any  dependency  on  hop  codes. 
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•  rcvr_fhcode; 

This  integer  procedure  returns  the  current  value  of  the  receiver's  hop  code. 

•  rcvr_in_sync; 

This  Boolean  procedure  returns  a  value  of  true  if  the  receiver  is  in  sync  and  false  if  it  isn’t. 

•  collisiondetected; 

This  Boolean  procedure  returns  a  value  of  true  if  a  collision  state  has  occured  since  the  last 

time  the  collision  flag  was  cleared. 

•  clearcollisionflag; 

A  call  to  this  procedure  clears  the  collision  flag. 

•  setscndcollisionlim  (I); 

The  argument  /  is  an  integer  that  gives  the  number  of  secondary  collisions  (same  channel  but 

different  codes)  that  a  receiver  can  tolerate. 

•  rcvrcollim; 

This  integer  procedure  returns  the  current  collision  limit  setting. 

•  numprimsignals; 

This  procedure  call  returns  the  number  of  primary  signals  currently  being  received. 

•  numscndsignals; 

This  procedure  call  returns  the  number  of  secondary  signals  currently  being  received. 

The  procedures  listed  above  form  a  subset  of  commands  that  may  be  used  to  program  a  communication 
controller.  The  commands  just  given  control  receivers.  We  introduce  the  commands  for  transmitters 
in  section  “Transmitter”  and  discuss  more  general  concepts  and  additional  commands  in  section  “Con¬ 
troller.” 

Class  receiver  provides  several  virtual  procedures  that  may  be  redefined.  Rcvrstat  and  rcvr  graf 
are  the  counterparts  of  chanstat  and  chan  graf  that  were  discussed  in  detail  in  section  “Channel.”  In 
addition,  class  receiver  provides  two  Boolean  virtual  procedures  that  may  be  redefined.  Their  default 
definitions  follow: 


BOOLEAN  PROCEDURE  collisionjest; 

INSPECT  station. mltcplr  DO 

collisiontest:  — (IF  numprimcollisions(rchannel,rfhcode)>  1  THEN  TRUE 
ELSE  num_scnd_collisions(rchannel)>scnd_collistonJim); 

BOOLEAN  PROCEDURE  cannotsync; 
cannotsync:  =  FALSE; 

The  default  procedure  for  collision  test  inspects  the  station’s  (i.e.,  layerl  node’s)  multicoupler  in  order 
to  access  the  counters  that  contain  current  state  information  on  the  number  of  primary  and  the  number 
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of  secondary  collisions.  If  a  primary  collision  state  exits  (num_prim_collisions>  1 )  or  if  the  number  of 
secondary  collisions  exceeds  the  secondary  collision  limit,  synchronization  with  any  transmitter  can  nei¬ 
ther  be  achieved  nor  maintained.  If  this  does  not  adequately  model  the  performance  of  the  receiver  in 
a  collision  state,  procedure  collision  test  may  be  redefined  in  a  subclass  of  receiver.  There  may  exist 
other  conditions  in  a  real  receiver  besides  the  collision  state  that  could  preclude  synchronization.  For 
example,  it  might  be  necessary  to  set  the  receiver  for  the  proper  transmission  rate  before  it  can  achieve 
synchronization.  Layerl  receiver  objects  can  be  tailored  to  respond  to  other  sets  of  synchronization  con¬ 
ditions  by  virtually  redefining  procedure  cannot  sync.  The  default  procedure  shown  above  always 
returns  a  false  value;  therefore,  it  will  never  interfere  with  a  receiver's  ability  to  synchronize. 

The  last  virtual  procedure  contained  in  class  receiver  is  real  procedure  timetosync.  The  default 
definition  is  as  follows: 

REAL  PROCEDURE  time  to  sync;  time_to_sync:=0,0; 


The  value  returned  by  a  call  to  time_to_sync  is  used  to  schedule  an  event  that  synchronizes  the 
receiver.  Section  “Layerl  Events”  explains  this  more  fully.  To  obtain  a  nonzero  synchronization  time, 
procedure  time  to  sync  must  be  virtually  redefined  in  a  subclass  of  receiver. 


Transmitter 

Transmitter  objects  are  created,  initialized,  and  activated  in  the  same  fashion  as  receiver  objects 
were.  The  appropriate  code  is: 


xmtr  (num)  NEW  transmitter!  transmitter  object  title  ,  THIS  node  ,  num  ); 
xmtr  (num)  .identify  cntri  (cntrlnum)  ; 

ACTIVATE  xmtr  (num)  ; 


Just  as  with  receiver  objects,  the  user  accesses  transmitter  objects  by  means  of  a 
controller  subprogram  interface  that  provides  the  following  procedures: 

•  select  xmtr  (id); 

The  argument  id  is  an  integer  that  designates  which  transmitter  the  interface  is  currently 
active  for.  If  there  is  only  one  transmitter,  this  procedure  need  not  be  called. 

•  read  xmtr  num; 

This  integer  procedure  returns  the  current  value  of  id. 

•  setxmtrchannel  (c); 

The  argument  c  is  an  integer  that  designates  the  channel  being  selected.  C  is  used  as  an  index 
to  REF(channel)  ARRAY  chansU  :max_num_of_chans)  which  is  an  array  of  pointers  to  chan¬ 
nel  objects. 
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•  xmtrchannelnum; 

This  integer  procedure  returns  the  index  of  the  channel  currently  used  by  the  transmitter. 

•  setxmtrfhcode  (J); 

The  argument  /is  an  integer  that  designates  the  frequency  hop  code  being  selected. 

•  xmtrfhcode; 

This  integer  procedure  returns  the  designator  of  the  frequency  hop  code  currently  used. 

•  set  xmtr  info  rate  (r); 

The  argument  r  is  an  integer  that  designates  the  new  transmission  rate  selected.  Information 
bits/s  would  be  an  appropriate  choice  of  units  in  many  cases;  however,  another  choice  of  units 
would  be  acceptable.  The  choice  should  be  compatible  with  the  unit  of  length  chosen  for 
isomsgs. 

•  xmtrinforate; 

This  integer  procedure  returns  the  current  transmission  rate. 

•  tum_on_xmtr; 

This  procedure  turns  the  transmitter  on.  It  does  not  initiate  the  transmission  of  information, 
but  it  does  send  a  carrier  that  initiates  receiver  synchronization  and  can  be  collision  detected 
by  receivers  that  have  connectivity  with  the  transmitter. 

■>  turnoffxmtr; 

This  procedure  turns  the  transmitter  off. 

•  start  (msg); 

The  argument  msg  is  an  iso_msg  that  is  packed  in  a  chan_msg  and  begins  transmission  at  the 
moment  this  procedure  is  called.  The  transmitter  must  be  in  an  idle  state  (i.e.,  turned  on  and 
not  sending  another  chan  msg)  for  this  procedure  call  to  take  effect.  If  a  start  is  attempted 
when  the  transmitter  is  not  idle,  a  warning  message  is  printed. 


Class  transmitter  has  two  additional  procedures  that  may  be  virtually  redefined— xmtrstat  and 
xmtr  graf.  These  procedures  are  analogous  to  chan_stat  and  chan  graf  previously  discussed  in  the  sec¬ 
tion  “Channel”. 


Controller 

A  controller  object  manages  a  set  of  communication  assets,  receivers  and  transmitters,  and  grants 
controllersubprograms  access  to  these  assets  according  to  a  user  specified  protocol.  Process  class  con¬ 
troller  contains  two  interfaces.  The  first  is  an  interface  for  controller  subprograms  to  use  in  accessing 
transmitter  and  receiver  objects.  A  controllersubprogram  uses  this  interface  to  create  the  interface 
presented  to  the  user  as  discussed  in  the  sections:  “Multicoupler,”  “Receiver,”  and  “Transmitter.” 
The  other  interface  is  designed  to  be  used  by  an  operating  system  that  has  the  task  of  scheduling  the 
controller  subprograms  assigned  to  the  controller.  The  operating  system  is  written  as  a  subclass  of  con¬ 
troller.  The  simplest  example  is  that  of  an  operating  system  which  initiates  the  execution  of  one  subpro¬ 
gram  and  after  that  does  nothing  more  as  shown  here. 
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controller  CLASS  opsystem; 

BEGIN 

subprg(l):-NEW  subprog (merge_text(“ subprog  for  cntrlltl  at  node  ”, 
int  text  (station. id  num)),station,“subprog",THIS  controller); 
ACTIVATE  subprog; 
run_sp(“subprog") ; 

END  of  opsystem; 

The  code  to  create  and  activate  the  controller  object  just  discussed  is  the  following; 


cntrl  (num)  NEW  opsystem  (THIS  node  ,  num  ); 

ACTIVATE  cntrl  (num); 

The  new  object  thus  created  is  a  subclass  of  controller.  The  actions  of  controller,  which  link  the  con¬ 
troller  with  its  transmitters  and  receivers  and  initialize  the  interface  to  be  active  for  transmitter  1  and 
receiver  1.  are  executed  first,  and  then  they  are  followed  by  the  actions  of  opsystem. 

In  a  more  complicated  example,  an  operating  system  program  that  regularly  swaps  two 
controllersubprograms  (say,  subprog  1  and  subprog2)  with  period  2t  can  be  written  as  follows; 

controller  CLASS  opsystem(t);  REAL  t;  !  t  is  time  to  run  before  swapping; 

BEGIN 

subprg(l):-NEW  subprogl  (mergetext  (“subprogl  for  cntrll  at  node", 

int  text  (station. id  num)), station, “subprogl’.THIS  controller); 
subprg(2):-NEW  subprog2  (merge  text  (“subprog2  for  cntrll  at  node", 

int_text(station.id_num)), station, “subprog2",THIS  controller); 

ACTIVATE  subprog(l);  ACTIVATE  subprog(2); 

loop: 

run  sp (‘  ‘subprogl") ; 

HOLD(t); 
runsp(“subprog2") ; 

HOLD(t); 

GOTO  loop; 

END  of  opsystem; 

The  first  two  actions  of  opsystem  are  to  create  subprogl  and  subprog2  and  pass  their  pointers  to 
REF(controller  subprogram)  ARRAY  subprg(l:max_num_of_subprograms).  Procedure  run_sp  uses 
these  pointers  to  halt  the  currently  running  subprogram  and  start  running  the  subprogram  named  as 
run  sp’s  argument.  Hold  is  a  class  simulation  procedure  that  schedules  opsystem  for  reactivation  at  a 
simulation  time  equal  to  current  simulation  time  plus  time  t,  which  is  hold’s  argument.  Thus,  execu¬ 
tion  of  loop  causes  subprogl  to  be  activated  and  then,  after  time  t,  subprogl  to  be  halted  and  subprog2 
to  be  activated.  After  another  time  /  the  cycle  repeats  itself  ad  infinitum  until  the  simulation  is  ter¬ 
minated. 

Besides  runsp  the  operating  system  interface  also  provides  a  procedure  called  halt_sp.  Runsp 
actually  calls  haltsp  to  halt  the  currently  operating  subprogram  before  activating  the  next  one.  How¬ 
ever,  haltsp  may  be  called  independently,  in  which  case  no  subprogram  will  be  running  in  the  con¬ 
troller. 

Controller  Subprogam 

Layer  I  can  model  the  case  of  several  networks  sharing  the  same  set  of  transmitters  and  receivers. 
For  example,  as  in  the  case  of  HF  Long  Haul  and  HF  Intrabattle  Group  Networks  sharing  the  same  HF 
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communications  suite,  the  controller  acts  as  the  arbiter  that  says  which  network  has  access  to  the  com- 
munication  assets  at  the  current  time.  Each  network  has  a  controllersubprogram  associated  with  it  that 
implements  the  link  layer  protocol  for  the  corresponding  network.  Protocols  for  higher  layers  may  also 
be  built  on  top  of  the  link  layer  protocol  if  desired. 

In  sections  “Multicoupler”  and  “Receiver”  we  have  discussed  many  of  the  procedures  that  form 
the  controller_subprogram  interface.  However,  the  preceding  discussions  are  not  complete  without 
mentioning  three  procedures  that  must  be  virtually  redefined  in  a  subclass  of  controller  subprogram  — 
msg_sent,  msg_ret  and  msg  rcvd.  These  three  procedures  are  called  by  layer  1  and  their  actions  are 
specified  by  the  user  in  a  subclass  of  controller  subprogram.  A  description  follows: 

•  msgsent  (isomsg,  t  id) ; 

When  a  transmitter  completes  its  transmission  of  an  iso_msg  (as  the  contents  of  a  chanmsg), 
the  transmitter  calls  this  procedure  with  a  pointer  to  the  isomsg  just  sent  and  the 
transmitter’s  integer  index  as  its  arguments.  This  informs  the  user's  protocol  (as  implemented 
in  the  controller  subprogram  subclass),  that  the  iso_msg  it  previously  started  has  been  sent 
and  now  it  is  time  to  initiate  another  action— perhaps  to  get  another  iso  msg  out  of  a  queue 
and  start  transmitting  it  or  perhaps  to  turn  off  the  transmitter. 

•  msgret  (isomsg.tid) ; 

In  the  event  a  transmitter  is  turned  off  while  an  iso_msg  is  being  transmitted,  the  transmitter 
will  call  this  procedure.  Perhaps  the  user  would  like  to  place  the  aborted  iso  msg  in  a 
retransmission  queue.  If  so,  the  msg  ret  procedure  can  be  programmed  for  that  action. 
Perhaps  the  user  would  like  to  discard  the  iso_msg  without  taking  any  further  action.  In  that 
case,  msg  ret  may  be  defined  without  any  actions. 

•  msgrcvd  (isomsg.rid) ; 

This  procedure  is  called  by  a  receiver  when  a  chan_msg  is  received.  The  iso  msg  is  unpacked 
from  the  chan  msg  to  become  the  actual  parameter  for  the  call  to  msg_rcvd.  Chan  msgs  are 
demarcated  by  start  of  msg  and  end_of_msg  events.  Msg_rcvd  is  not  called  until  the 
end_of_msg  event  is  received.  A  call  to  this  procedure  informs  the  user’s 
controller  subprogram  subclass  that  the  receiver  with  index  number  rid  has  received  an 
isomsg. 

The  three  procedures  described  above  complete  the  set  of  procedures  provided  by 
controller  subprogram  as  an  interface  to  the  layer  1  transmitter  and  receiver  objects. 

Controllersubprogram  defines  another  procedure  that  may  be  called  by  the  user,  but  it  is  not  a 
part  of  the  interface  to  transmitter  and  receiver  objects.  The  procedure  is  named  designate  clock  and  is 
called  as  follows: 


subprg  (num)  .designate  clock  (process  name)  ; 

The  process  object  pointed  to  by  process  name  serves  as  a  clock  mechanism.  It  is  not  necessary  to  asso¬ 
ciate  a  clock  with  a  controller_subprogram,  but  it  can  be  useful.  Since  it  is  a  process  class,  the  clock 
may  use  procedure  hold  to  schedule  synchronous  events  for  its  controller  subprogram.  Of  course, 
controller  subprogram  is  also  a  subclass  of  process,  but,  since  it  is  an  event-process,  a  call  to  hold  will 
yield  unpredictable  results  [5].  Therefore,  to  schedule  synchronous  events  for  a  controller  subprogram. 
one  should  create  a  separate  process  object  to  serve  as  a  clock.  However,  if  the  controller  is  running 
more  than  one  controller  subprogram,  the  clock  should  be  running  only  while  its  associated 
controller  subprogram  is  executing.  Stopping  and  starting  a  clock  mechanism  is  handled  behind  the 
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scene  by  procedures  in  controllersubprogram  as  long  as  the  procedures  have  access  to  a  pointer  that 
designates  the  clock— hence,  procedure  designateclock. 

This  concludes  our  discussion  of  layer I  objects.  In  a  following  section  we  study  an  example  of  a 
carrier-sense  multiple-access  protocol  written  in  the  layer !  context,  which  illustrates  most  of  the 
material  presented  in  this  section.  However,  before  launching  into  the  example,  we  wish  to  explain 
how  layer!  uses  events  to  model  the  transmissions  of  a  communication  system.  This  we  endeavor  to 
do  in  the  next  section. 

LAYER1 EVENTS 

Layer!  uses  events  to  model  the  transmission  process  in  a  communication  system.  By  under¬ 
standing  how  the  occurrence  of  one  event  leads  to  the  occurrence  of  other  events  and  how  it  produces 
state  changes  in  the  communication  system  model,  one  is  able  to  see  how  layer!  works.  To  aid  in  gain¬ 
ing  this  understanding,  we  now  introduce  the  concept  of  an  event  graph  17] .  We  take  some  liberty  with 
event  graphs  as  they  are  formally  presented  in  Ref.  7,  and  therefore  give  the  following  explanation  of 
the  conventions  we  use  in  this  report. 

Figure  4  shows  our  event  graph  conventions.  Events  are  depicted  as  circles  connected  by  directed 
edges.  Each  circle  is  tagged  with  the  event  name  and,  in  some  cases,  the  lower  half  of  the  circle  is  used 
to  indicate  a  new  system  state.  All  events  create  new  system  states;  however,  we  do  not  always 
rigorously  spell  out  these  new  states  in  the  event  diagrams.  Where  a  new  state  is  indicated,  it  is 
entered  after  the  occurrence  of  the  event,  not  before. 


condition  state 


Fig  4  —  Event  graph  conventions 


Directed  edges  indicate  causality  between  events.  Edges  may  be  tagged  with  conditions  and/or 
delay  times.  If  the  edge  is  tagged  with  a  condition  it  is  marked  with  a  to  indicate  its  conditional 
nature.  Conditions  always  represent  some  combination  of  state  variables  (i.e.,  system  state)  which 
must  be  satisfied  for  an  event  to  occur.  Moreover,  the  condition  must  be  satisfied  at  the  time  of 
occurrence  of  the  causing  event,  not  after  it  has  occurred.  Thus,  the  new  state  indicated  in  the  lower 
half  of  the  causing  event's  circle  has  not  yet  been  entered  at  the  time  the  condition  must  be  tested.  If  a 
delay  time  is  given,  the  event  thus  scheduled  will  occur  at  a  time  equal  to  the  time  of  occurrence  of  the 
causing  event  plus  the  delay  time. 


15 


•  ,•  V  *-•  *.*  V  *.*  V  *,•  *,*  *.*  *,•  •*  Vs  »**  .*•  .*•  A  ,*•  *’*’►*• 

■*u>'  »VA«V»V»>ij.,yAVfc  -V  -V-’*  -V-NVv  A  >.N» 


L  V  f. —\4 


J.P.  HAUSER  AND  D  J  BAKER 

Two  more  conventions  complete  our  set  of  event  graph  tools.  If  a  state  or  a  condition  has  a  line 
above  it,  the  opposite  is  indicated  and  may  be  read  as  “not.”  Also,  a  dashed  edge  indicates  the  cancel¬ 
ing  of  an  event  as  opposed  to  the  scheduling  of  an  event. 

With  these  event  graph  tools  we  are  now  ready  to  diagram  the  workings  of  layerl  objects,  that  are 
presented  in  Figs.  5  and  6.  The  process  of  transmitting  a  message  is  shown  in  Fig.  5,  and  the  process 
of  receiving  a  message  is  shown  in  Fig.  6. 


1/2  interface 


transmitter 


channel 
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multicoupler  receiver  1/2  interlace 


In  Figs.  S  and  6  we  use  one  other  convention  not  directly  associated  with  event  graphs,  that  is  the 
use  of  boxes  to  denote  objects.  The  box  at  the  far  left  of  Fig.  5  represents  a  controllersubprogram 
object.  The  events  or  procedure  calls*  listed  there  are  scheduled  by  a  user  defined  protocol  that  must 
implement  some  kind  of  channel  access  scheme.  This  box  is  the  interface  to  layerl.  We  have  not 
shown  the  interface  in  its  entirety  here  in  order  to  avoid  unnecessary  clutter  in  the  event  diagram.  The 
parts  of  the  interface  essential  for  understanding  layerl  message  transmission  are  included. 

The  real  work  of  transmitting  an  isomsg  is  done  by  the  box  in  the  middle,  the  transmitter  object. 
If  we  ignore  channels  and  codes  for  a  moment,  we  see  that  a  transmitter  object  has  three  fundemental 
states  —  sending,  idle,  or  off.  All  edge  conditions  are  related  to  one  of  these  states.  For  example,  to 
start  a  message  the  transmitter  must  be  in  the  idle  state.  The  idle  slate  means  that  the  transmitter  has 
been  turned  on  but  is  not  sending  any  information.  One  could  view  it  as  a  transmitter  sending  an 
unmodulated  carrier.  If  the  transmitter  has  not  been  turned  on  or  if  it  is  in  the  process  of  sending  a 
message,  then  calling  start  with  a  new  iso  msg  to  send  will  have  no  effect,  except  that  layerl  will  return 
a  warning  message  to  the  user  appraising  him  of  the  situation.  But,  if  the  transmitter  is  idle,  starting  a 
message  immediately  queues  a  msg  arrived  while  idle  event  which,  in  turn,  schedules  unconditionally 
a  start  of  msg  event  in  the  channel  and  an  end_of_msg  event  delayed  by  the  message  transmission 
time  in  the  transmitter.  The  transmitter  state  is  then  set  to  sending.  Upon  completion  of  the  transmis¬ 
sion  the  transmitter  endofmsg  event  occurs  and  in  turn  schedules  an  endofmsg  event  for  the  chan¬ 
nel  and  calls  the  virtual  msg  sent  procedure  back  in  the  controller  subprogram  interface  where  the 
user’s  protocol  must  decide  what  to  do  when  a  message  has  been  sent.  The  actions  to  be  taken  upon 
completion  of  a  message  transmission  become  the  actions  programmed  in  the  virtual  definition  of  the 
msg  sent  procedure. 


*  The  uniqueness  of  an  event  is  that  it  may  be  scheduled  for  activation  in  a  time-ordered  event-queue.  When  an  event  gets  to 
the  top  of  the  event-queue,  and  thus  becomes  current,  the  actions  it  causes  become  the  active  part  of  the  simulation  This  is 
precisely  what  happens  when  a  procedure  call  is  made  -  i  c  .  the  actions  of  the  procedure  become  the  active  part  of  the 
simulation  Therefore,  in  a  special  case  when  an  event  is  scheduled  for  immediate  activation,  it  behaves  not  differently  than  a 
procedure  call  In  fact,  a  procedure  call  can  accomplish  the  same  result  as  scheduling  an  event  for  immediate  activation  in  the 
event-queue  The  controller  subprogram  interface  happens  to  be  implemented  with  procedure  calls,  but  it  is  not  improper  to 
graph  these  procedure  calls  as  events  for  the  reason  just  given 
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Calls  to  turn  off  and  turn_on  in  the  controllersubprogram  interface  conditionally  schedule  events 
by  the  same  name  in  the  transmitter.  The  rationale  for  imposing  these  conditions  should  be  fairly  obvi¬ 
ous.  If  the  transmitter  is  already  off,  a  call  to  turn  off  should  have  no  effect.  Thus,  the  transmitter 
has  to  be  in  a  “not"  off  state  (i.e.,  either  idle  or  sending)  to  schedule  a  turn  off  event.  Conversely,  the 
transmitter  must  be  off  for  a  turn  on  event  to  be  scheduled.  Both  turn  off  and  turn  on  events  uncon¬ 
ditionally  schedule  corresponding  events  in  the  channel.  However,  if  a  transmitter  is  turned  off  while  it 
is  sending  a  message,  a  little  extra  work  must  be  done  to  tidy  things  up.  The  end_of_msg  event  which 
had  been  scheduled  for  the  end  of  the  transmission  must  be  canceled  and  a  virtual  procedure  msg  ret  is 
called  to  force  the  user’s  protocol  to  do  something  about  the  aborted  transmission.  Of  course,  if  the 
user  merely  wants  to  allow  the  aborted  message  to  fall  on  the  floor,  his  virtual  redefinition  of  msg  ret 
need  take  no  action. 

The  set  channel  and  set  code  events  may  only  be  scheduled  if  the  transmitter  is  not  sending,  i.e., 
is  off  or  idle.  When  code  or  channel  changes  are  made  while  the  transmitter  is  in  an  idle  state,  addi¬ 
tional  xoff  and  xon  events  must  be  scheduled  in  the  channel  so  that  receiving  nodes  can  sort  out  what 
is  going  on.  Xon  and  xoff  events  are  always  tagged  with  the  channel  and  code  of  the  transmitter 
scheduling  them. 

The  channel  object  has  the  task  of  forwarding  all  startofmsg,  endofmsg,  xon,  and  xoff  events 
to  the  multicouplers  at  those  nodes  with  which  the  transmitter  using  the  channel  has  connectivity.  If 
the  channel  happens  to  be  designated  as  dynamic  the  task  is  slightly  more  complicated  because  the 
channel  must  generate  some  xon’s  and  xoff  s  of  its  own  to  model  the  effects  of  changing  connectivities. 
However,  this  is  done  behind  the  scene  so  that  the  user  need  not  be  concerned  with  it.  The  user  needs 
only  be  concerned  with  keeping  the  connectivity  matrix  up  to  date. 

In  Fig.  6  we  diagram  the  effects  of  the  start  of  msg,  end  of  msg,  xon,  and  xoff  events  as  they 
are  received.  Reception  is  contingent  upon  having  connectivity  with  the  sending  transmitter  by  means 
of  a  channel,  as  the  conditions  used  to  tag  the  far  left  edges  in  Fig.  6  indicate.  The  multicoupler  inter¬ 
cepts  xon  and  xoff  events  to  increment  and  decrement  collision  counters  within  the  multicoupler. 
Events  are  then  forwarded  to  any  receiver  at  the  node  tuned  to  the  channel  that  is  sending  the  events. 
If  the  receiver  is  not  already  in  sync  and  is  not  in  a  collision  state,  the  xon  event  will  schedule  a 
syncdetected  event  delayed  by  the  time  required  to  obtain  synchronization.  The  length  of  time 
required  is  computed  by  a  call  to  the  procedure  timetosync,  which  may  be  virtually  redefined  in  a 
subclass  of  receiver  (section,  “Receiver”).  Xon  and  xoff  events  can  conditionally  cancel  the 
sync  detected  event  at  a  receiver.  If  the  xon  event  causes  a  collision  state  to  occur  at  the  receiver,  then 
the  receiver  is  not  able  to  attain  synchronization.  Thus  the  sync  detected  event  is  canceled.  Also,  if 
the  transmitter  that  caused  the  sync  detected  event  to  be  scheduled  sends  an  xoff,  the  sync  detected 
event  must  be  canceled.  Changing  the  channel  and  code  settings  of  a  receiver  also  cancels  a 
sync  detected  event  that  has  been  scheduled.  Start_of_msg  and  end  of  msg  events  can  be  scheduled  at 
the  receiver  only  if  the  receiver  is  set  to  the  proper  code  as  well  as  the  proper  channel  and  is  in  sync,  as 
is  indicated  by  the  edge  conditions.  The  start  of  msg  event  sets  a  reference  variable  called  currentmsg 
to  point  to  the  incoming  chanmsg.  The  end  of  msg  event  calls  a  virtual  procedure  msgjrcvd  in  the 
controller  subprogram  interface  as  long  as  the  chan  msg  causing  the  end  of  msg  event  is  the  same  one 
that  caused  the  start  of  msg  event.  The  user’s  protocol  then  must  decide  what  to  do  with  a  message 
that  has  been  received  by  redefining  the  virtual  procedure. 

AN  EXAMPLE 

To  illustrate  the  use  of  the  layerl  context  we  show  how  to  code  a  simple  carrier-sense  multiple- 
access  (CSMA)  protocol.  An  event  diagram  of  the  protocol  is  shown  in  Fig.  7.  To  develop  a  layer2 
protocol  we  do  not  need  to  know  anything  about  layerl  other  than  how  to  use  its  interface.  In  the  adja¬ 
cent  box  we  show  the  procedures  we  shall  use  from  the  interface  to  implement  the  protocol.  Over  on 
the  right-hand  side  of  the  diagram  we  have  another  interface  — the  2-3  interface.  The  2-3  interface  con¬ 
tains  the  procedures  we  want  our  network  layer  to  use.  We  model  the  network  layer  and  above  very 


Fig.  7  —  Event  graph  of  a  CSMA  protocol 


simply  by  creating  a  traffic  generator  to  generate  the  message  traffic  at  each  node  and  by  creating  a 
message  handler  that  merely  gets  incoming  messages  and  prints  them.  To  design  the  protocol,  there¬ 
fore  one  should  simply  fill  in  the  box  between  the  two  interfaces  with  a  meaningful  event  diagram,  as 
we  have  done. 

Now  we  are  ready  to  examine  the  CSMA  protocol.  If  we  wish  to  send  a  message  via  the  2-3 
interface,  we  call  the  2-3  interface  send  procedure.  A  call  to  this  procedure  puts  the  message  in  a 
queue  —  xq  —  and  schedules  an  accesschannel  event  if  the  protocol  is  not  already  in  an  accessing 
state.  When  an  access_channel  event  occurs,  the  protocol  checks  to  see  if  the  channel  is  idle  (not 
busy).  If  it  is,  the  protocol  turns  on  the  transmitter  and  starts  a  message  —  the  first  message  in  xq, 
which  is  an  FIFO  queue.  If,  however,  the  channel  is  busy,  the  access_channel  event  reschedules  itself 
to  occur  at  some  random  delay  time  later.  In  either  case,  the  protocol  enters  an  accessing  state,  which 
means  that  it  is  attempting  —  either  successfully  or  unsuccessfully  —  to  access  the  channel. 


The  rest  of  our  CSMA  protocol  is  implemented  by  redefining  the  virtual  procedures  msgsent, 
msg  ret,  and  msg  rcvd.  When  the  transmission  of  a  message  is  completed,  we  must  decide  what  to  do 
next  by  appropriately  redefining  the  msg  sent  procedure.  At  this  point  we  turn  off  the  transmitter  and, 
if  xq  has  more  messages,  we  schedule  an  access  channel  event.  If  xq  is  now  empty  however,  we 
schedule  a  terminateaccess  event  which  changes  the  protocol's  state  to  not  accessing.  In  other  words, 
once  the  protocol  gains  access  to  the  channel,  it  keeps  on  sending  messages  until  xq  is  empty.  This 
protocol  will  tend  to  maintain  a  high  throughput  with  some  sacrifice  of  message  delay  time.  The  proto¬ 
col  could  likely  be  enhanced,  but  we  only  intend  for  it  to  illustrate  simulation  design  techniques  not 
optimum  protocol  design. 
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The  definitions  of  the  remaining  virtual  procedures  in  the  1-2  interface  are  quite  simple  Msg  ret 
merely  prints  out  an  error  message.  If  our  code  properly  implements  the  event  diagram  we  should 
never  see  this  message.  If  we  do  see  it,  it  will  aid  in  debugging  the  code.  Msgrcvd  puts  the  incoming 
message  into  an  FIFO  queue  —  rq  —  and  queues  an  event  for  the  next  higher  protocol  that  causes  it  to 
respond  to  the  incoming  message.  The  code  that  implements  this  event  diagram  is  presented  in  the 
appendix. 

CONCLUSIONS 

The  work  presented  in  this  report  has  several  significant  aspects.  The  first  is  the  development  of 
the  layer!  code  and  the  context  that  supports  it.  Layer I  has  the  capability  of  modeling  the  physical 
layers  of  many  different  types  of  communication  systems.  Moreover,  this  capability  is  accessible 
through  an  easy  to  use  interface.  Secondly,  and  perhaps  of  greater  significance,  is  that  the  techniques 
used  to  construct  the  layerl  code  can  be  readily  extended  to  simulate  the  protocols  of  each  of  the 
higher  layers  of  the  ISO/OSI  reference  model.  Each  new  class  thus  written  can  become  the  supporting 
context  for  the  next  higher  ISO  layer  protocol.  This  creates  an  exact  parallel  between  the  code  that 
implements  the  simulation  and  the  system  being  modeled.  Finally,  by  using  event  graphs  we  have 
introduced  a  very  useful  technique  for  describing  the  simulation  model  apart  from  writing  the  code.  A 
Careful  inspection  of  the  code  presented  in  the  appendix  shows  that  the  event  graph  of  our  CSMA  pro¬ 
tocol  maps  rather  directly  into  SIMULA  code.  We  believe  the  methodology  presented  in  this  report  to 
be  both  unique  and  powerful. 
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APPENDIX 


The  code  for  our  example  is  written  as  two  separate  blocks.  The  first  is  layer l  class  Iayer2.  Thus, 
layer 2  is  developed  in  a  layer  1  context.  Most  of  the  code  defines  new  subclasses  of  layer  1  object  tem¬ 
plates.  Also,  we  redefine  virtual  procedure  prop_delay. 

•  real  procedure  propdelay 

To  model  the  effects  of  propagation  delay  we  must  redefine  this  procedure.  The  code  used  in 
our  example  reads  in  a  single  propagation  delay  value  to  be  used  for  all  node  pairs. 

•  isomsg  class  csmamsg 

Here  we  define  a  subclass  of  iso_msg.  We  merely  wish  to  add  a  few  attributes  to  iso  msg  — 
contents,  serno  and  origtime.  The  contents  of  a  csma_msg  is  a  netmsg.  Netmsgs  originate 
in  the  layer  above  layer2  and  become  the  contents  of  layer2  messages,  i.e.,  csmamsgs.  In  the 
same  way  csma  msgs  become  the  contents  of  chan  msgs,  which  are  the  messages  of  layerl. 
Csma  msgs  also  have  their  own  serial  numbers  and  origination  times. 

•  event  msg  class  net  msg 

Net  msg  must  be  defined  in  layer2  so  that  contents,  which  is  a  formal  parameter  of  class 
csma  msg,  may  be  properly  typed  as  a  net  msg  reference  variable.  Net  msg  is  prefixed  with 
event  msg  enabling  us  to  use  net  msgs  as  arguments  for  events.  We  have  not  used  that  capa¬ 
bility  in  this  example.  However,  prefixing  message  classes  with  event  msg  can  make  the  code 
easier  to  extend. 

•  layerlnode  class  linknode 

Linknode  has  the  task  of  creating  the  objects  that  will  serve  as  a  layerl  node’s  communica¬ 
tion  facilities.  Here  we  create  a  transmitter  and  a  receiver.  We  delay  the  creation  of  the  con¬ 
troller  and  controllersubprogram  until  the  highest  level  protocol  has  been  defined. 

•  controller  subprogram  class  csmaprog 

This  subclass  provides  the  essence  of  our  CSMA  protocol.  Most  of  the  event  graph  shown  in 
Fig.  7  is  implemented  here.  The  protocol  is  written  in  the  context  of  the  lower  level  interface 
which  services  it  —  in  this  case,  controller  subprogram  that  is  the  interface  to  layerl. 

•  csma  prog  class  linknetinterface 

This  subclass  provides  the  2-3  interface  shown  in  Fig.  7.  The  interface  itself  is  written  in  the 
context  of  the  lower  layer  protocol  for  which  it  serves  as  an  interface.  Thus,  it  is  prefixed 
with  csma  prog. 

Layer2  becomes  the  new  context  for  the  higher  ISO  layers  of  our  example.  The  code  for  Iayer2  follows: 

EXTERNAL  CLASS  I  I J e .  I  ; 

I  ft j  «  v I  CLASS  layer!; 

BEGIN 

INTEGER  *  e  r  ao  ceaat e  r  ; 

REAL  p  I  a  jr  ; 
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REAL  PROCEDURE  p r o p  d e  I  a y  ( o J  .  n 2  )  ;  REFHayerloodelnl  ,o2; 
propdelay  :«p  4c  la;  ; 

PROCEDURE  r ci4  4c  I  • y  ; 

BEGIN 

prompt  ('Give  •  value  for  propagation  delay  '  )  , 
p  delay  :  ~  I  a  r  e  a  I  ; 

END  ; 

c  v  e ■ I  «» |  CLASS  act  m  s  g  (  lea);  INTEGER  lea;; 

hi  mi |  CLASS  ciai  ds| ( coni tnt i ) ;  REFlnetmsgbcontenls; 
BEGIN 

INTEGER  s  e  r  a  o  ; 
real  o  r  I  g  t  l me  ; 


•  i  i|l  lac  :*(  I  me  ; 

END  of  data  msg; 

INTEGER  PROCEDURE  get  ser  no. 

get  «ef  ter  ic  coviltr:”  ser  no  counter-fl; 

layer!  node  CLASS  liokoode; 

V  I  R1  CAL  :  PROCEDURE  create  objedi  at  node; 

BEGIN 

PROCEDURE  ertate  object)  at  node; 

BEGIN 

t«t  r  <  I  )  :  •  N EW  t  nmol  t  ter 

(neigc  teilCiolr  I  at  node  *,int  text(ld  numb). 

THIS  link  node,  1);  lat  r ( I  I  .  Idenl  i f  y  ea  t  r I  (I)  ;  ACTIVATE  xmtr(l); 
r  c  v  r  (  I  I  :  -  N  E  W  receiver  (merge  teitf’rcer  I  at  node  ‘.Int  teitfld  ovm) 
THIS  I  I  nk _ node  .  I  . 0 )  ;  r  c  v  r  <  1  >.  I  d  e  a  t  l  f  y  c  n  t  r  I  <  I  >  ;  ACTIVATE  rcvr(l) 
END  of  create  ebjecti  at  node; 

cteile  object)  at  node; 

END  of  link  node; 

controller  aabprograa  (LASS  oai  prog; 

BEGIN 

BOOLEAN  accenlig; 

INTEGER  r«  seed; 

REF  la) g  g I ig  ,  tg  ; 

PROC  EDURE  prologue  . 

BEGIN 

prlatl merge  I e  a  t  ( *  I  a  pa  t  data  for  node  a  ,  lat  t ett  h l at  ion  .  I!  oia)  I  )  ; 
promptt’kii  rate  (bp)  I  *1.  tel  tatr  laforatedtreal); 

prompt  (*  ret  raaialta  ioa  teed:  *);  ri  teed  :*lalal  ; 
xg:-  NEW  at  g  gtilal  Ioa,*  transmit  g  *  . NONE )  ; 

H  :  ■  N  EW  msg  gtstat  loo,  *  receive  g*  . NONE >  ; 

END  ; 

PROCEDURE  handle  ig; 

IE  NOT  accessing  THEN  access  chaaael; 

PROCEDURE  send; 

BEG  I  N 

REF ( c  sma  asglmtg; 

IF  ig.|el  (asg.lnel  THEN 
BEGIN 

taraoa  tmlr; 
s  t  a  r  t  (ms  g  b  ; 

END 

ELSE  print  (  *  E R  ROR  no  msg  in  ig*  I  ; 

END  of  send. 


PROCEDURE  access  chaaael  ; 

BEGIN 

REF (at |  g I  % ; 

REF  I  etna  at | I  msg. 
accessing  :"TRUE; 

IF  aim  prim  i I |aa I tal  THEN  sead 
ELSE  ACTIVATE  NEW  event (THIS  etna  prog, 
'esma  prog,  access  c h a  a  a e  I  '  .  NONE b  delay 
aalforad  l.l  I  ,  n  seed!. 

END  of  access  chaaael; 

PRO(  EDI  R  E  lermlaate  access,  accessing  -•FALSE. 
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P  ROC  E  DIR  E  ns|  xol  <ns|,ialr  14)  ;  RtF I csm»  ms | lot |  ;  I  NT  EG  ER  *  m I  r  l 4  ; 

BEGIN 

turn  off  xml r; 

INSPECT  ililloo  QUA  link  node  OO 

IF  i q . f I r s t ““NONE  THEN  t e  r m i a  a t  e  a c c e s s 

ELSE  access  channel; 

END  of  msfsenl; 

P  ROC  E DU  RE  msgretfmsg.xmtrid);  REF(csmamsg)msg;  INTEGER  xml  r  id; 

BEGIN 

Outtcxt(*csma  msg  *);  Oul  iol  <ffli|.s(r  do,4)  ; 

Ouilexti*  aborted  in  esmaprog:  ‘I; 

Outtcxt  (title);  Out  image; 

END; 

PROCEDURE  msg  rcvdlmsg.rid);  REF(csmamsg)msg;  INTEGER  rid; 

BEG  I  N 

rq.put (msgl ; 

ACT  I VATE  NED  event  (THIS  csmaprog.’net  prog,  handle  rq*  , NONE )  ; 

END  ; 

IF  evtype*’ prologue*  THEN  prologue 
ELSE  IF  evdesti  not  ioo“*csma  prog*  THEN 
BEGIN  task; 

IF  evtype«’acce*s  channel*  THEN  term  tbiooel 
ELSE  IF  evtype“’haodlexq*  THEN  handlexq 

ELSE  pi  ini  (‘Unrecognized  event  received  by  esmaprog’); 

END  ; 

END  of  csoa  prog; 

esmaprog  CLASS  link  net  interface; 

BEGIN 

PROCEDURE  sendmsg(msg);  REF (net  msg)  msg; 

BEGIN 

x  q  .  p  u  t  <  N  E  VS  esna  msgloMg.  len.msg)); 

ACTIVATE  NEW  evenl  (THIS  1  Ink  net  Interface, ‘esma  prog. handle_xq*, NON E )  ; 
END; 

REF (net  msg)  PROCEDURE  get  msg (q) ;  REFtmsg  q)q; 

BEGIN 

REF ( esma  msg )ms  g  ; 

IF  q . g e t (ms g , TRUE )  THEN  get  msg:  msg.coDltoti 

ELSE  print  (mergetexf  ( *  ERROR  -  msg  NOT  available  in  ’  , q .  title)); 

END  of  g  c  t  ms  g  ; 

END  of  I  iok  net  interface; 

readdelay; 

END  of  I  a  y  e  r  2  ; 


The  second  block  is  not  a  context.  Rather,  it  is  our  main  block  that  defines  our  higher  layer 
objects  (that  could  not  be  defined  in  the  physical  or  link  layers)  and  provides  the  actions  to  execute  the 
simulation. 

•  net  msg  class  datamsg 

We  extend  the  definition  of  netmsg  by  defining  a  subclass  that  adds  the  attributes  serno  and 
origtime.  This  gives  our  network  layer  message  the  same  attributes  useful  for  tracing  and 
statistics  collection  included  in  the  messages  of  lower  layers. 

•  controller  class  cl  opsys 

This  subclass  of  controller  creates  the  controllersubprogram  with  all  its  subclasses,  netprog 
being  the  innermost  subclass  to  be  defined.  The  concatenated  object,  beginning  with 
controller  subprogram  and  ending  with  net  prog,  contains  all  the  protocols  and  interfaces  that 
we  have  defined.  The  subclass  of  controller  —  cl  opsys  —  acts  as  an  operating  system  by 
scheduling  the  controller  subprogram  for  execution.  Scheduling  in  this  example  is  trivial 
since  all  that  is  required  is  a  call  to  run  sp  to  get  things  started. 
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•  link  node  class  net.node 

Here  we  give  a  node  a  few  more  objects  that  could  not  be  defined  in  the  lower  layers  —  a 
controller  (cl_opsys)  and  a  traffic  generator. 

•  linknetinterface  class  netprog 

We  use  this  subclass  of  link  net  interface  to  build  our  layer  3-7  receiving  protocol,  which 
merely  prints  out  incoming  messages. 

•  process  class  trafficgenerator 

The  trafficgenerator  models  the  sending  portion  of  the  layer  3-7  protocol.  It  also  uses  the 
2-3  interface,  in  this  case  to  send  messages. 

The  main  block  ends  with  several  actions  that  prompt  for  event  tracing,  create  the  node  objects,  start 
the  simulation,  prompt  for  the  simulation  period,  and  reschedule  the  main  block  at  the  end  of  the 
simualtion  period.  The  code  follows: 


BEGIN 

EXTERNAL  CLASS  I«jer2; 

I •;<  r  2  1 1  •  .  t  ,  1  .  ■  * 

BEGIN 

REAL  slmptrlaj; 

INTEGER  counter; 

net  msg  CLASS  daft  ms  g  ; 

BEGIN 

REAL  o  r  I  g  t  l at ; 

INTEGER  ter.no; 
o  r  I g  t  l me  : -T i  me  ; 
ter  no coouter  :  — c  on • t  e  r +  1  ; 

END; 

controller  CLASS  c  I  _ o p t y t  ; 

BEGIN 

stbpri ( I ) : - N EW  net  prog 

(me r g et e x t ( ‘ a e tp r o g  FOR  cntrl  I  at  ioie  ‘  ,  int  teit  (mi  ion.lt  nia)), 
>lnl  Ion,  ’net  .prog'  .THIS  control  ler)  ; 

ACTIVATE  tukprg(l)  ; 
rm.tpCact  png'  I  ; 

END  of  clopsyt; 

liokaotfe  CLASS  net  node; 

BEGIN 

REFItvafficgeneratorlgen; 

citrl(l);-  NEW  c I . o p a f t I TH I S  link  node.  1);  ACTIVATE  cnlrl(l); 
gen;-  N  EW  traffic  generator  (cntrl  (1)  .  tnbprg (II)  ; 

ACTIVATE  gen; 

END  of  net  node; 

I  ink  net  Interface  CLASS  net  prog; 

BEGIN 

PROCEDURE  p  r  o  I  ogne  ;  ; 

PROCEDURE  hand  I  erg  . 

BEG  I  N 

REF (dal  a  ntglnsg  ; 

aig  -gel  nt g  (  r  g  )  ; 

Out  text  ('Process  msg  *);  Oil  Ini  (nig.ier  no.t); 

Oittexl  (‘  at  *);  Oil  I tx I  ( 1  I  I  I e )  ;  Oil  inige ; 

END; 

IF  ei  l  jip*"'  pro  I  ogie  ‘  THEN  prologue 
ELSE  IF  Mdti  I  loot  I  on*' ic I  prog*  THEN 
BEGIN 
task; 

IF  e  v  l  y  p  e»'  h  a  a  4  I  e  r  g  '  THEN  li  a  n  4  I  e  _  r  g 

ELSE  pr  111  (nr  r  ft  .  ml  ri«r«f*|»l  nd  event  In  net  prog.  ,  e  v  t  y  p  a  )  I  ; 
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Process  CLASS  t raf (I t ,|tat ni «r (  later ficc)  ; 

REF (  I  lik  ael  liltr(ict)  interface; 

BEGIN 

KEF(lati.ntf)  mi; 

INTEGER  t  g  _  a  e  c  4  ; 

REAL  ncmie.rite; 

REAL  me  * • a g e _ I e a ■ t h ; 

P  r  amp  t  (  *  me  a  s  a  |  e  geieralnr  aet4  *);  t  |  a  e  e  4  :  ■*  I  a  I  n  t  ; 
p  r  nmp  t  (  "me  a  a  a  |  e  _  r  1 1  e  (#/ml  a  .  )  ');  meaaaie.rate  ;•  lareal/M.I; 

prompt  Cminaie  J<a|t  h  (Pita)  ");  meaaige  I  e  a  g  l  h  :  •  I  n  r  e  a  I  ; 

PASSIVATE; 

WHILE  TRUE  DO 
BEGIN 

HOLD (Negesp4meaange_rate . t|.aee4>>  ; 
m a  g :  •  NEW  4  a t a _ma | ( me  a  a  a g e _ I e n g t h )  ; 
interface. sen4_mag (mag) ; 

END; 

END  af  t  raff  I c.ienerat nr  ; 

PROCEDURE  i tar l  i Inn  I  a  t I aa ;  !Uaer  i k  at  I  4  call  this  at  appropriate  time 
BEGIN 

INTEGER  i; 

FOR  !:-!  atep  1  UNTIL  nnmafna4ei  DO  ACTIVATE  na4ee(i)  QUA  nct_na4e.g 
END  af  a t a r t _ • imn I  a t I en ; 

PROCEDURE  create.akjeeti; 

BEGIN  INTEGER  l;~ 

eraata.phri.ckaaid,  FALSE)  ; 

chant  (1)  .caan.  t  I  I  I  cenaed  i  r  i  t  j  aa trig; 

FOR  I:  — I  atep  I  UNTIL  nnmafai4ei  DO  ai4ti ( l ) : •  NEW  act  ia4i ( I , I , 1 , 1 ) 
END  af  creale.akjecta; 


prampt  CNamkcr  nf  na4ea  *);  a  nma  f  a  a  4  e  a  : « I  a  1  a  t  ; 
prampt  ('Brent  tracing?  (  y  /  a  )  :  "); 

IF  |H  Jlai-V  THEN 
BEGIN 

event  _ I  race : -TRUE ; 

prampt ('Eater  a  trace  apec:  "); 

t  race  epee  :  -gat  line; 

END; 

c  r aa  t  e_ahj acta; 
ilart.s Imalal  Ian; 

prampt ('Ealir  the  nlmalal Ian  perin4  (tec):  ");  t Imper Ia4 :>lnrea I ; 
HOLD ( a Imper Ia4) ; 

END; 

END; 
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